Do not use direct IP allocation for isolated networks with SpecifyIpRanges - #14087
Conversation
GuestNetworkGuru.allocate() called allocateDirectIp() whenever a network had SpecifyIpRanges set, but that path allocates from the zone's VLAN public pools and is only correct for shared networks. An isolated network with SpecifyIpRanges then failed to get an address from its own CIDR and threw InsufficientAddressCapacityException once the public pools were exhausted. Gate the direct allocation on the shared guest type so isolated networks fall through to their normal CIDR allocation. Fixes: apache#12772
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #14087 +/- ##
=========================================
Coverage 19.78% 19.79%
- Complexity 19995 19998 +3
=========================================
Files 6371 6371
Lines 575909 575909
Branches 70509 70509
=========================================
+ Hits 113950 113975 +25
+ Misses 449526 449506 -20
+ Partials 12433 12428 -5
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
@nagaboinaramgopal |
Yes, reproduced and verified live on a KVM advanced zone. Repro steps:
Results, before this change: Step 4 fails even though the /24 CIDR still has plenty of free addresses, because allocate() takes the allocateDirectIp path (direct pool) for the Isolated network and never uses the network CIDR: Results, after this change (same network, direct range still exhausted): Step 4 now succeeds, and the VM gets 10.199.50.9 from the /24 CIDR, outside the exhausted 10.199.50.10-13 direct range, so allocation comes from the network CIDR as expected. Shared networks are unchanged. The unit test covers the same behaviour: for an Isolated network with SpecifyIpRanges, allocate() no longer calls allocateDirectIp. |
2 participants
Description
GuestNetworkGuru.allocate() called allocateDirectIp() for any network that has SpecifyIpRanges set. That path allocates from the zone's VLAN public pools and is only correct for shared networks. An isolated network with SpecifyIpRanges then tried to take an address from the public pools instead of its own CIDR, and failed with InsufficientAddressCapacityException once those pools were exhausted, even though the network's own CIDR still had free addresses.
This gates the direct allocation on the shared guest type, so isolated networks fall through to their normal CIDR allocation. Shared network behaviour is unchanged. This matches the fix suggested by weizhou in the issue.
Fixes: #12772
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
N/A
How Has This Been Tested?
Added unit tests on the base guru's allocate(). For an isolated network with SpecifyIpRanges the test checks that allocateDirectIp is not called and the address comes from the network CIDR instead; before this change that test fails because allocateDirectIp is called. For a shared network with SpecifyIpRanges the test checks that allocateDirectIp is still called, so shared allocation is unchanged.
How did you try to break this feature and the system with this change?
Kept a shared network test to make sure the direct allocation path is untouched for shared networks. The only behaviour that changes is an isolated network with SpecifyIpRanges, which now uses its own CIDR the same way an isolated network without SpecifyIpRanges already does.